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Remarks 

I. Status of the Application 

Claims 1-46 are pending in the application. 

IL Claim Rejections 35 USC § 103 

Claims 1-46 have been rejected under 35 USC § 103(a) as being allegedly 
unpatentable over U.S. Patent No. 7,051,002 ("Keresman") in view of U.S. Patent Publication 
No. 2005/0010488 ("Itakura"). The rejection is respectfully traversed. 

A. Claim 1 

Keresman does not teach "determining, by the processor, the format type of the 
request from among a plurality of predetermined second format types" and "identifying, by the 
processor, a host computer configured to process the determined format type from among a 
plurality of host computers, each host computer being configured to process at least one of the 
predetermined second format types," where the processor is at a merchant site, as required by 
claim 1. Itakura does not teach the claimed processing, either, Even if it did, however, it would 
not have been obvious to combine Keresman and Itakura as the Examiner has. 
L Keresman 

Keresman discloses a centralized merchant processing system for safely 
authenticating payments and facilitating the processing of electronic transactions via the Internet. 
(Col. 4, lines 45-53). Keresman explains that current systems used in e-commerce place 
considerable burdens upon the merchant to participate in authentication initiatives. (Col. 2, lines 
43-66). Keresman explains that some existing systems require a merchant to install a plug-in 
component that receives a payment authorization request from a consumer and passes a "verify 
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enrollment request" along to a server operated by a credit card network, (Col. 1, line 64 - col. 2, 

line 5). Without describing in detail the capabilities and functions of the merchant plug-in 

component, Keresman explains that installation and maintenance of such merchant plug-in 

components can be burdensome to the merchant, as stated at Col. 2, lines 50-64: 

"installation of the merchant plug-in can be overly burdensome 
using up resources, i.e., computing power, memory data storage 
capacity, etc., the merchant would otherwise prefer to devote to 
other tasks. Often, the plug-in component can be extremely large 
and/or cumbersome to implement on the merchant's server. 
Moreover, for a merchant that participates in a plurality of such 
authentication programs for multiple credit card networks, the 
burden can be that much more, i.e., requiring a separate plug-in 
component for each individual authentication initiative they wish 
to support, especially considering that each credit card network 
may have its own particular protocols, data fields that are 
employed in the respective messages, specific data format 
requirements, etc." 

Accordingly, Keresman discloses a "thin-client" located at the merchant's site 
which contains minimal processing capability. Keresman explains that "the thin-client 106 is a 
small software component installed on the merchant's server 100," and that the thin-client "does 
not hold any payment authentication specific business process logic." (Col. 6, lines 26-27, 51- 
53). Keresman further states that the merchant can use the thin-client 'Vithout significant 
reprogramming of the server 100 or their web site." (Col. 6, lines 40-43). 

The "thin-client" located at the merchant's site obtains information relating to a 
transaction, and sends the transaction details to a merchant authentication processing system 
("MAPS") located at a central location (not at the merchant's site). (Col. 5, lines 22-65). The 
consumer selects the type of payment instrument (Visa, MasterCard, etc.), and the thin-client 
communicates transaction data elements such as card-number, transaction amount, etc., to the 
MAPS system. (Col. 6, lines 4-14, 21-24). 



3I584251.DOC 



- 14- 



Docket No.: 23122.1014 

Upon receiving payment information from a thin-client, the MAPS system 
determines the type of payment instrument being used based on the payment information. For 
example, the MAPS may determine which payment processing network a credit card belongs to 
from the card number. (Col. 10, lines 7-11). After determining the payment instrument type, the 
MAPS system authenticates the consumer. (Col. 9, lines 47-50). 

As discussed above, independent method claim 1, in contrast, requires 
determining, by the processor which is located at a merchant site, "the format type of the request 
from among a plurality of predetermined second format types" and "identifying, by the 
processor, a host computer configured to process the determined format type from among a 
plurality of host computers, each host computer being configured to process at least one of the 
predetermined second format types." The Examiner admits that Keresman "does not explicitly 
teach [determining a format] from among a plurality of second format types and [identifying a 
host computer] from among a plurality of host computers, each host computer being configured 
to process at least one of the predetermined second format types," but alleges that Itakura does. 
The applicant respectfully disagrees. 

2. Itakura 

Itakura discloses a system for ordering goods safely using both the World Wide 
Web and a private network. Itakura explains that security throughout the World Wide Web is 
"poor," and that *Vhen transmitting the credit card number and the expiration date through the 
World Wide Web, such information can be misused, which is undesirable." [0026]. Therefore, 
Itakura discloses a system comprising multiple terminals connected to an "information provider," 
which connects to the World Wide Web and allows users to place orders for goods. (Paragraph 
[0068]). The terminals are also connected to a payment system 35 that includes a message 
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distribution system 39 and computers of multiple credit card corporations 28. The system 39 and 
the credit card corporations communicate through a private (closed) network 27. ([0069)]. Bills 
are paid through the private network. ([0027]). 

In one disclosed example, a payment request including an order ED number and 
store code is transmitted from a terminal 10 to an information provider 20 to the "message 
distribution system 39" along a private line. The system 39 retrieves the credit card number and 
expiration date from a database it maintains, and sends this information to one of the credit card 
corporations 28 through the private (closed) network 27. ([Paragraphs [0095]-[0096]). The 
credit card corporation verifies the credit card, and returns an acknowledgment message to the 
system indicating that the payment has been processed. ([0096]). The "message distribution 
system 39" is not located at a merchant site. 

In another disclosed example, the user inputs credit card information (including 
credit card number and expiration date), which is transmitted to the message distribution system 
39 via the information provider 20 and private line. The system 39 sends the credit card 
information to a credit card corporation 28. (Paragraphs [0106]-[0107]). 

Itakura does not explain where, if anywhere, a determination of the "format type" 
of a payment request and identification of the host computer configured to process the particular 
format type, are made. 

Accordingly, Itakura does not teach determining, by a processor located at a 
merchant site , "the format type of the request from among a plurality of predetermined second 
format types," as required by claim 1. (Emphasis added). Itakura merely states that certain 
information is transmitted through the private network to a credit card corporation "to confirm if 
the credit card is valid." The credit card corporation verifies the credit card and processes the 



3158425I.DOC 



-16- 



Docket No.: 23122.1014 

payment. There is no discussion whatsoever of any processor located at a merchant site that 
determines a "format" of a credit card, as claimed. 

In addition, Itakura does not teach "identifying, "by the processor, located at the 
merchant site," a host computer configured to process the determined format type from among a 
plurality of host computers," as required by claim 1. Itakura merely states that certain 
information is transmitted through the private network to a credit card corporation "to confirm if 
the credit card is valid." There is no disclosure that any processor associated with a merchant, 
such as the "terminal 10" or the "information provider 20," identifies a host computer "from 
among a plurality of host computers," as claimed, 

3. Keresman and Itakura Cannot be Combined As the Examiner Proposes 

a. Modifying Keresman in Light of Itakura Does not Result in the Claimed 
Invention 

The Examiner appears to assert that it would have been obvious to combine 
Keresman and Itakura in order to transmit credit card information in a secure manner by a private 
network. However, use of a private network is not a claim limitation. Furthermore, the private 
network in Itakura merely conveys the transaction information fi-om the message distribution 
system 39 to a credit card corporation shown within the payment system 35, which is not at the 
merchant site. As discussed above, there is no teaching or suggestion in Itakura to provide the 
claimed processing at the merchant site. Whether a private network is advantageous or not is 
not, therefore, relevant to the type of processing done at a merchant site. The Examiner has not, 
therefore, identified a proper teaching or suggestion to provide a processor at the merchant site to 
determine a format type among a plurality of format types or to identify a host computer 
configured to process the format type, among a plurality of host computers. 
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b* The Thin Client at the Merchant Site in Keresman is not Capable of 
Performing the Claimed Processing 

The "thin client" in Keresman, which has minimal processing capability, does not 

appear to be capable of holding sufficient software to determine a "format type" of a request 

from among a "plurality of predetermined format types" or of identifying a host computer from 

among a plurality of host computers, as claimed. Keresman specifically states that the thin client 

is a "small software component" that "does not hold any payment authentication specific 

business process logic," as discussed above. Therefore, Keresman cannot be modified by Itakura 

in the manner proposed by the Examiner. 

c. The Proposed Modification Would Render Keresman Unsatisfactory For Its 
Intended Purpose 

If a proposed modification would render the prior art invention being modified 
unsatisfactory for its intended purpose, then there is no suggestion or motivation to make the 
proposed modification. MPEP 2143.01, V. 

As explained above, Keresman' s intended purpose is to reduce the burden 
imposed upon merchants by minimizing the size of the software plug-in component that the 
merchant must install at the merchant's site. Keresman emphasizes that installation of a 
merchant plug-in "can be overly burdensome using up resources, i.e., computing power, memory 
data storage capacity, etc., the merchant would otherwise prefer to devote to other tasks," as 
discussed above. To minimize the burden on the merchant, Keresman provides a "thin-client" 
which comprises a "small software component" that the merchant can use 'Vithout significant 
reprogramming of the server," and performs authentication at a centralized location rather than at 
the merchant level. Adding software at the merchant site capable of determining a format of a 
request, as required by claim 1, would increase rather than decrease the burden upon the 
merchant. Thus, even if Itakura did teach or suggest determining, by a processor located at a 
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merchant site, "the format type of the request from among a plurality of predetermined second 
format types" (which it does not), as alleged by the Examiner, combining Itakura and Keresman 
would be improper because such a combination would contradict the intended purpose of 
Keresman. 

d. Keresman Teaches Away From The Proposed Modiflcation 

Furthermore, Keresman indicates multiple times that it is preferable not to 
perform the processing of payment transactions on the merchant's computer (as would occur in 
the proposed combination of Keresman and Itakura), but instead to consolidate the processing of 
payment requests at a central location. For example, Keresman states that use of the centralized 
MAPS system, away from the merchant site, "leads to an easy implementation at the merchant 
website level, i.e., where the processing logic and message handling prescribed by the 
[authentication] initiatives are controlled at a central location rather than at an individual 
merchant level." (Col. 7, lines 15-20). Also, as mentioned above, Keresman states that the "thin 
client approach" enables the merchant to "participate within the various payment authentication 
initiatives... without any significant reprogramming of the server." (Col. 6, lines 36-43). 
Keresman lists many reasons why including authentication functionality to a merchant-level 
plug-in is cumbersome and burdensome to the merchant, and intentionally provides a system that 
minimizes the processing required at the merchant site, as discussed above. 

Keresman, therefore, clearly teaches away from use of a "processor" located at 
the merchant's site to determine a format of a request from among a plurality of format types 
and/or to identify a host computer configured to process the determined format type from among 
a plurality of host computers, as the Examiner has proposed. MPEP 2146 X.D.2. 
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e, Itakura Teaches Away From The Proposed Modification 

Itakura also teaches away from the proposed combination. As discussed above, 
Itakura' s stated purpose is to provide a safe network through which payment for goods purchased 
via the World Wide Web can be made. Itakura clearly states that security is poor when 
transmitting information over the World Wide Web, and that making payment via the World 
Wide Web carries the risk that credit card information may be misused. [0026]. Itakura thus 
intentionally avoids using the Internet to transmit and process payments, and instead uses a 
private network to do so. Itakura, therefore, teaches away from the combination proposed by the 
Examiner, which would use the "server 100" and the "MAPS 200" described in Keresman to 
communicate payment requests via the Internet. (See page 3 of the Office Action). 

Because the proposed combination would contradict the intended purpose of 
Keresman, and because both Keresman and Itakura teach away from the proposed combination, 
the rejection is improper and should be withdrawn. 

None of the other cited art teaches or suggests the combination of claim 1, either. 
Therefore, claim 1 and its dependent claims are patentable over the cited art. 

B. Claim 19 

Independent claim 19 defines a system located at a merchant site for processing 
an electronic payment transaction. Claim 19 requires a processor located at a merchant site, 
configured to "determine the format type of the request from among a pluralitv of predetermined 
second format tvpes ." For the reasons discussed above, none of the cited art teaches or suggests 
this limitation. Therefore, claim 19 and its dependent claims are patentable over the cited art. 
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C. Claims 11 and 29 

Independent claim 1 1 defines a method for settling a plurality of electronic 
payments. Independent claim 29 is a system claim that corresponds to claim 11. Claims 1 1 and 
29 require determining, by a processor, "the format type of each respective data packet from 
among a plurality of predetermined second format types," and identifying "a host computer 
configured to process the determined format type of each respective data packet." For reasons 
similar to those set forth above with respect to claim 1, none of the cited art teaches or suggests 
this limitation. Therefore, claim 1 1 and its dependent claims, and claim 29 and its dependent 
claims, are patentable over the cited art. 

D. Claim 44 

Independent claim 44 defines a method to process electronic payment 
transactions. Claim 44 requires "receiving, by a processor located at a merchant site, a plurality 
of requests to process electronic payment transactions from a plurality of payment terminals 
located at the merchant site and separate from the processor, each request having a respective 
format type," "determining, by the processor, the format type of each request," and "identifying, 
by the processor, a host computer configured to process each determined format type." As 
discussed above, none of the cited art teaches or suggests this combination. Therefore, claim 44 
is patentable over the cited art. 

E. Claims 45 and 46 

Independent claim 45 defines a system to process electronic payment transactions. 
Claim 45 requires a processor separate from the plurality of terminals and located at the 
merchant site configured to "receive, from the plurality of terminals, a plurality of requests to 
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process one or more electronic payment transactions, each request having a respective format 
type," "determine the format type of each request" and "identify a host computer configured to 
process each determined format type." Independent claim 46 is a method claim that corresponds 
to claim 45. 



For the reasons discussed above, none of the cited art teaches or suggests the 



combination of claims 45 and 46. Therefore, claims 45 and 46 are patentable over the cited art. 
III. Conclusion 



In view of the foregoing, each of claims 1-46 is believed to be in condition for 



allowance. Accordingly reconsideration of the claims and allowance of the application are 
respectfully requested. 
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